我們己經聊過SOLID、依賴反轉、低耦合、高內聚，這些觀念，是在決定是否有能夠執行單元測試的重要前提。

1. 為何要寫單元測試？

筆者之前在工作環境，跟其他同仁分享單元測試的概念時，同仁的反應大概就是……

• 幹嘛寫測試，軟體測試的事情給測試的同仁負責就好了。
• 單元測試很好，但手上工作這麼多，那來的時間再多寫一個測試程式。
• 寫了單元測試，程式就一定不會出錯嗎？會出錯幹嘛要再花時間寫。
• 手上的程式碼，它太複雜了，跟本沒有辦法寫測試程式。

1.1 單元測試應該給誰寫

幹嘛寫測試，軟體測試的事情給測試的同仁負責就好了。

有些公司專門的測試部門來進行測試。對測試的同仁而言，他們的測試方向比較偏向黑箱測試、整合測試，只能知道程式最後輸出的結果為何。就算最後的結果出現錯誤。完全無法得知是那個環結出錯。

單元測試主要目的，是確保程式碼內，商業邏輯的正確。

在筆者的認知中，單元測試主要的目的，應該是要測試**程式碼內，商業邏輯是否正確與否。**也就是，開發某一個功能的當下，我們應該是非常明確的知道，當輸入什麼資料，預期會得到什麼結果。

而單元測試，就是為了快速測試、驗證，我們所開發的功能，是否能達到預期的結果。對於通過測試的功能，就可以保證它的商業邏輯，在特定的測試的條件是正確無誤的。

假若，程式真的在整合測試中，出現異常。因為程式功能經過單元測試，就可以排除己通過測試的部份，有效的縮小問題的範圍。

1.2 你一定寫過測試程式

單元測試很好，但手上工作這麼多，那來的時間再多寫一個測試程式。

1.3 發揮 POWER 的時間點

寫了單元測試，程式就一定不會出錯嗎？會出錯幹嘛要再花時間寫。

如果說，寫了單元測試，程式就一定沒問題。絕對是天方夜談。或許，寫時間寫單元測試，只是為了當下測試功能是否正確，感覺小題大作了點。

單元測試，真正發揮它的 POWER 的時間點，在於軟體後續長期維護、需求變動、重構時，就是有效避免錯誤的再次發生。

但是……

單元測試，真正發揮它的 POWER 的時間點，在於軟體後續長期維護、需求變動、重構時，才能真正的明白為什麼需要單元測試。

看倌一定有經驗，當軟體規模大到一個程度後，後面的需求變動，往往有很大的機率出現改 A 壞 B的情況。在單元測試保護的情況下，程式改壞了，測試就會直接亮紅燈，以確保程式功能的正確性。

1.4 為什麼無法寫單元測試？

2. 應該要注意的要點

3. 盡可能避免

3.1 過度測試

4. 後言

關於單元測試，網路上有很多優秀的文章，例如 91 大的「30 天快速上手 TDD」或是本次鐵人賽的其他作者的文章，各位看倌都可以去好好的研讀。每位作者切入的點，都會有所差異，也許當中的某一篇文章，就讓看倌收獲良多了。

5. 推薦

5.1 文章

• In91, 30天快速上手TDD系列

持續補寫中